[レポート] オブザーバビリティ: モダンなアプリケーション向けベストプラクティス #COP344 #reinvent

AWS re:Invent 2022

#Amazon CloudWatch

#AWS X-Ray

#AWS Distro For Opentelemetry

#AWS

川崎照夫

2023.03.31

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

アノテーションテクニカルサポートの川崎です。

本記事は AWS re:Invent 2022 のセッションレポートとなります。

概要

アプリケーションの中断や運用上のインシデントに直面した場合、顧客に影響が及ぶ前に、できるだけ早く問題を解決することが重要です。モダンなコンテナ化またはサーバーレスアプリケーションの場合、分散型の性質により、このチャレンジはさらに困難になります。このセッションでは、モダンなアプリケーションアーキテクチャのオブザーバビリティのベストプラクティスを学びます。 AWS オブザーバビリティサービスを使用して、アプリケーションの問題を迅速に特定、診断、修正する方法をご覧ください。

セッション動画

アジェンダ

1 なぜモダンなアプリケーションは観察が難しいのか?
2 インストルメンテーション(計測) オプションのナビゲート
3 高カーディナリティのコストの最適化
4 過剰アラームによる疲弊を緩和
5 宙ぶらりんトレースを回避

1. なぜモダンなアプリケーションは観察が難しいのか?

モダンなアプリケーションの複雑さ

モノリシックアプリケーション
サービス
マイクロサービス

マイクロサービスは…

どのように監視しますか?
- 疎結合
- 自立（ストレージあり）
- 独立して展開
- 水平方向にスケーリング
- さまざまな環境でホスト
- ポリグロット
- ステートレス

モダンなアプリケーションの複雑さ

モノリシックアプリケーション
マイクロサービス

ソフトウェアにおけるオブザーバビリティ

ソフトウェアシステムでは、オブザーバビリティとは、プログラムの実行、モジュールの内部状態、およびコンポーネント間の通信に関するデータを収集、関連付け、分析する機能です。

オブザーバビリティが重要な理由

可視性
リアルタイムのトラブルシューティング
顧客体験
アプリケーション = $$

運用上の課題 → ビジネス課題

Everything fails all the time. (「全ては壊れる」ことを前提に)
Werner Vogels
VP and CTO, Amazon

モダンなアプリへの戦略的アプローチ

戦略的アプローチ

AWS サーバーレスファーストのアプローチ (AWS Lambda、AWS App Runner、Amazon ECS、AWS Fargate)
- 最初の選択肢として AWS マネージドサービスとツールを使用する
- お客様の多くは、プロビジョニング、DevOps、インフラストラクチャの自動化、セキュリティ、ネットワーキング、オブザーバビリティ/運用など、AWS に関する分野の開発に投資しています。
- 生産性と最小限の運用負担
- Lambda とコンテナを含む
AWS 上の Kubernetes (+++) (AWS 上の Amazon EKS、Red Hat OpenShift)
- 主要なコンピューティングプラットフォームインターフェイスとしての Kubernetes
- 多くのお客様が、Kubernetes を実行する主要な場所として AWS を選択しています
- 複数の Kubernetes クラスターとそれらのワークロードとツールの実行と管理に関する規律を採用する - GitOps などの高度なパターン
- 豊富なエコシステムとパートナーツール
- 多くの Kubernetes のお客様は、マネージド AWS サービスや、特定のユースケースでLambda などのその他のコンピューティングオプションを利用しています。

AWS オブザーバビリティオプション

ベストプラクティス

インストルメンテーション(計測) オプションのナビゲート
高カーディナリティのコストの最適化
過剰アラームによる疲弊を緩和
宙ぶらりんトレースを回避

2. インストルメンテーション(計測) オプションのナビゲート

インストルメンテーションは責任共有です

お客様
- カスタムメトリクス
- カスタムログ
- トレースインストルメンテーション
AWS
- Vended metrics
- Vended logs
- Vended traces

Vended metrics

Vended logs

Vended traces

カスタムインストルメンテーション

AWS Lambda
Amazon Elastic Container Service (Amazon ECS)
Amazon Elastic Kubernetes Service (Amazon EKS)

Lambda インストルメンテーション

LOGS

Lambda インストルメンテーション

METRICS

Lambda インストルメンテーション

TRACES

インストルメンテーションエージェント

AWS Distro for OpenTelemetry
CloudWatch agent
X-Ray Daemon
FireLens
Fluent Bit

OpenTelemetry

ホスト/VM/コンテナ
OpenTelemetry コレクター
バックエンド

インストルメンテーションの重要ポイント

SUMMARY

1 メトリクスとトレースに AWS Distro for OpenTelemetry (ADOT) を使用する
2 ロギングエージェント (CloudWatch または FireLens エージェント) を選択します。
3 OpenTelemetry 仕様
- トレース: GA
- メトリクス: GA
- ログ: Draft
4 将来的には、ログにも ADOT を使用していきます

ベストプラクティス

インストルメンテーション(計測) オプションのナビゲート
高カーディナリティのコストの最適化
過剰アラームによる疲弊を緩和
宙ぶらりんトレースを回避

3. 高カーディナリティのコストの最適化

高カーディナリティテレメトリ

高いカーディナリティの増加

高カーディナリティテレメトリ

VM 環境
- http_response
  - 2 つの環境
  - 10 サービス
  - 5 つのステータスコード
  - 10 インスタンス
- 1,000 の可能なメトリクス
- $300/月
クラウドネイティブ環境
- http_response
  - 2 つの環境
  - 100 サービス
  - 5 つのステータスコード
  - 10,000 タスク/ポッド
- 10,000,000 の可能なメトリクス
- $244,500/月

高カーディナリティテレメトリ

METRICS OR LOGS

メトリクス
- クエリが速い
- アラームを駆動
ログ
- 効率的なコスト
- 保存期間なし
メトリクスとログのどちらかだけでなく
- 両方使用
- CloudWatch Embedded Metric Format を使用

高カーディナリティテレメトリ

BEST OF BOTH WORLDS WITH LOGS AND METRICS

大幅なコスト削減につながる可能性

CloudWatch Embedded Metric Format のデモ

高カーディナリティテレメトリ

SUMMARY

1. 潜在的な高カーディナリティディメンションを特定する
1. 最初にテレメトリをログとして取り込みます
1. 次に、適切なディメンションを使用してメトリクスを作成します
1. CloudWatch を使用している場合は、Embedded Metric Format を活用します
1. OpenTelemetry には Embedded Metric Format エクスポーターがあります

ベストプラクティス

インストルメンテーション(計測) オプションのナビゲート
高カーディナリティのコストの最適化
過剰アラームによる疲弊を緩和
宙ぶらりんトレースを回避

4. 過剰アラームによる疲弊を緩和

過剰アラームによる疲弊を緩和

METRICS OR LOGS

メトリクス
アラーム

高カーディナリティテレメトリ

VM 環境
- http_response
  - 2 つの環境
  - 10 サービス
  - 5 つのステータスコード
  - 10 インスタンス
- 1,000 の可能なメトリクス
クラウドネイティブ環境
- http_response
  - 2 つの環境
  - 100 サービス
  - 5 つのステータスコード
  - 10,000 タスク/ポッド
- 10,000,000 の可能なメトリクス

過剰アラームによる疲弊を緩和

BEST PRACTICES

1 主要業績評価指標 (KPI) とワークロードメトリクスに関するアラーム
- 注文率
- 処理された注文数
- キューの深さ
2 ワークロードの結果が危険にさらされている場合に警告する
3 ワークロードの異常が検出された場合のアラート
4 イベントへの応答を自動化する

アラームを関連付ける

BEST PRACTICES

1 CPU 使用率が高いことは大きな警告ではありません
2 メモリ使用率は大きな警告ではありません
3 ただし、両方が同時に発生している場合は、良いアラームになる可能性があります
4 Microsoft IIS Web サーバーでは、これはアプリケーションプールがリサイクルされていることを意味します。
5 これにより、HTTP 要求の処理が一時停止され、ユーザーは気付くでしょう。

異常時のアラーム

BEST PRACTICES

1 統計および機械学習アルゴリズムを活用する
2 期待値の範囲を示す異常検出モデルを生成する
3 静的しきい値ではなく動的しきい値でのアラーム
4 メトリクスの急上昇や急降下には正当な理由がある場合があります。誤検知は望ましくありません

CloudWatch Composite Alarms と CloudWatch Anomaly Detection のデモ

過剰アラームによる疲弊を緩和

SUMMARY

1 KPI とワークロードメトリクスに関するアラーム
2 ワークロードの結果が危険にさらされている場合に警告する
- CloudWatch Synthetic Canaries
3 アラームを相関させ、その相関が発生したときに人に通知する
- CloudWatch Composite Alarms
4 機械学習アルゴリズムを活用して異常を検出する
- CloudWatch Anomaly Detection

ベストプラクティス

インストルメンテーション(計測) オプションのナビゲート
高カーディナリティのコストの最適化
過剰アラームによる疲弊を緩和
宙ぶらりんトレースを回避

5. 宙ぶらりんトレースを回避

トレースの伝播

WHAT IS A TRACEID?

トレースの伝播

HOW DOES PROPAGATION WORK?

トレースの伝播

HOW DOES PROPAGATION WORK?

トレースの伝播

HOW DOES PROPAGATION WORK?

トレースの開始

コンテナ
- アプリケーションのインストルメンテーション
クラウドネイティブ
- ケースによります

トレースの伝播

SERVICES THAT SUPPORT TRACING

API Gateway
App Mesh
App Runner
AWS AppSync
Amazon EC2
Elastic Load Balancing
CloudWatch RUM
EventBridge
Lambda
Amazon SNS
Step Functions
Amazon SQS
Amazon S3
CloudWatch Synthetics

AWS X-Ray と他の AWS のサービスの統合 - AWS X-Ray

Elastic Load Balancing

アプリケーションロードバランサーは、受信 HTTP 要求にトレース ID を追加します
ロードバランサーは X-Ray にデータを送信せず、サービスマップにノードとして表示されません

Lambda

X-Ray を有効にすると、Lambda がトレースを X-Ray に自動的に送信します
ダウンストリーム呼び出しをキャプチャするには、Lambda 関数でインストルメンテーションが必要です
X-Ray トレースは現在、Amazon MSK または Amazon MQ イベントソースマッピングを使用する Lambda 関数ではサポートされていません

Amazon EventBridge

X-Ray SDK でインストルメンテーションされたサービスがイベントを EventBridge に送信する場合、トレースコンテキストが伝達されます。
EventBridge は、トレースコンテキストを渡した PutEvents 要求からイベントが発生した場合にのみ、イベントのトレースヘッダーを渡すことができます。